System and method for determining a propensity of entity to take a specified action

ABSTRACT

Systems and methods are disclosed for determining a propensity of an entity to take a specified action. In accordance with one implementation, a method is provided for determining the propensity. The method includes, for example, accessing one or more data sources, the one or more data sources including information associated with the entity, forming a record associated with the entity by integrating the information from the one or more data sources, generating, based on the record, one or more features associated with the entity, processing the one or more features to determine the propensity of the entity to take the specified action, and outputting the propensity.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 14/562,524, filed on Dec. 5, 2014, which claimspriority to U.S. Provisional Patent Application No. 62/027,761, filed onJul. 22, 2014, and U.S. Provisional Patent Application No. 62/039,305,filed on Aug. 19, 2014, the disclosures of which are expresslyincorporated herein by reference in their entirety.

BACKGROUND

The amount of information being processed and stored is rapidlyincreasing as technology advances present an ever-increasing ability togenerate and store data. On the one hand, this vast amount of dataallows entities to perform more detailed analyses than ever. But on theother hand, the vast amount of data makes it more difficult for entitiesto quickly sort through and determine the most relevant features of thedata. Collecting, classifying, and analyzing large sets of data in anappropriate manner allows these entities to more quickly and efficientlyidentify patterns, thereby allowing them to predict future actions.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made to the accompanying drawings, whichillustrate exemplary embodiments of the present disclosure. In thedrawings:

FIG. 1 is a block diagram of an exemplary computer system, consistentwith embodiments of the present disclosure;

FIG. 2 is a flowchart of an exemplary method for determining apropensity of an entity to take a specified action, consistent withembodiments of the present disclosure;

FIG. 3 is a flowchart of an exemplary method for creating a model todetermine the propensity of an entity to take a specified action,consistent with embodiments of the present disclosure;

FIG. 4 provides an exemplary use case scenario for determining apropensity of an entity to take a specified action applied to anexemplary data structure, consistent with embodiments of the presentdisclosure.

FIG. 5 illustrates an exemplary user interface, consistent withembodiments of the present disclosure; and

FIG. 6 illustrates another exemplary user interface, consistent withembodiments of the present disclosure.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Reference will now be made in detail to several exemplary embodiments,including those illustrated in the accompanying drawings. Wheneverpossible, the same reference numbers will be used throughout thedrawings to refer to the same or like parts.

Embodiments disclosed herein are directed to, among other things, tosystems and methods that can determine the propensity of an entity(e.g., a person, a household, or a company) to take a specified action.For example, a specific action can involve determining the propensitythat a customer will leave a supplier during a given time period (e.g.,churn). Such factors that can affect the churn rate include customerdissatisfaction, cheaper and/or better offers from the competition, moresuccessful sales and/or marketing by the competition, or reasons havingto do with the customer life cycle. If a supplier can receive anindication that a customer is likely to churn, the supplier can take oneor more actions in order to keep the customer. The embodiments disclosedherein can assist with providing that indication.

For example, the systems and methods can access one or more datasources, the one or more data sources including information associatedwith the entity, form a record associated with the entity by integratingthe information from the one or more data sources, generate, based onthe record, one or more features associated with the entity, process theone or more features to determine the propensity of the entity to takethe specified action, and output the propensity.

The operations, techniques, and/or components described herein areimplemented by a computer system, which can include one or morespecial-purpose computing devices. The special-purpose computing devicescan be hard-wired to perform the operations, techniques, and/orcomponents described herein. The special-purpose computing devices caninclude digital electronic devices such as one or moreapplication-specific integrated circuits (ASICs) or field programmablegate arrays (FPGAs) that are persistently programmed to perform theoperations, techniques, and/or components described herein. Thespecial-purpose computing devices can include one or more hardwareprocessors programmed to perform such features of the present disclosurepursuant to program instructions in firmware, memory, other storage, ora combination. Such special-purpose computing devices can combine customhard-wired logic, ASICs, or FPGAs with custom programming to accomplishthe techniques and other features of the present disclosure. Thespecial-purpose computing devices can be desktop computer systems,portable computer systems, handheld devices, networking devices, or anyother device that incorporates hard-wired and/or program logic toimplement the techniques and other features of the present disclosure.

The one or more special-purpose computing devices can be generallycontrolled and coordinated by operating system software, such as iOS,Android, Blackberry, Chrome OS, Windows XP, Windows Vista, Windows 7,Windows 8, Windows Server, Windows CE, Unix, Linux, SunOS, Solaris,VxWorks, or other compatible operating systems. In other embodiments,the computing device can be controlled by a proprietary operatingsystem. Operating systems control and schedule computer processes forexecution, perform memory management, provide file system, networking,I/O services, and provide a user interface functionality, such as agraphical user interface (“GUI”), among other things.

By way of example, FIG. 1 is a block diagram that illustrates animplementation of a computer system 100, which, as described above, cancomprise one or more electronic devices. Computer system 100 includes abus 102 or other communication mechanism for communicating information,and one or more hardware processors 104 (denoted as processor 104 forpurposes of simplicity), coupled with bus 102 for processinginformation. One or more hardware processors 104 can be, for example,one or more microprocessors.

Computer system 100 also includes a main memory 106, such as a randomaccess memory (RAM) or other dynamic storage device, coupled to bus 102for storing information and instructions to be executed by one or moreprocessors 104. Main memory 106 also can be used for storing temporaryvariables or other intermediate information during execution ofinstructions to be executed by processor 104. Such instructions, whenstored in non-transitory storage media accessible to one or moreprocessors 104, render computer system 100 into a special-purposemachine that is customized to perform the operations specified in theinstructions.

Computer system 100 further includes a read only memory (ROM) 108 orother static storage device coupled to bus 102 for storing staticinformation and instructions for processor 104. A storage device 110,such as a magnetic disk, optical disk, or USB thumb drive (Flash drive),etc., is provided and coupled to bus 102 for storing information andinstructions.

Computer system 100 can be coupled via bus 102 to a display 112, such asa cathode ray tube (CRT), an LCD display, or a touchscreen, fordisplaying information to a computer user. An input device 114,including alphanumeric and other keys, is coupled to bus 102 forcommunicating information and command selections to one or moreprocessors 104. Another type of user input device is cursor control 116,such as a mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to one or more processors104 and for controlling cursor movement on display 112. The input devicetypically has two degrees of freedom in two axes, a first axis (forexample, x) and a second axis (for example, y), that allows the deviceto specify positions in a plane. In some embodiments, the same directioninformation and command selections as cursor control may be implementedvia receiving touches on a touch screen without a cursor.

Computer system 100 can include a user interface module to implement aGUI that may be stored in a mass storage device as executable softwarecodes that are executed by the one or more computing devices. This andother modules may include, by way of example, components, such assoftware components, object-oriented software components, classcomponents and task components, processes, functions, attributes,procedures, subroutines, segments of program code, drivers, firmware,microcode, circuitry, data, databases, data structures, tables, arrays,and variables.

In general, the word “module,” as used herein, refers to logic embodiedin hardware or firmware, or to a collection of software instructions,possibly having entry and exit points, written in a programminglanguage, such as, for example, Java, Lua, C, and C++. A software modulecan be compiled and linked into an executable program, installed in adynamic link library, or written in an interpreted programming languagesuch as, for example, BASIC, Perl, Python, or Pig. It will beappreciated that software modules can be callable from other modules orfrom themselves, and/or can be invoked in response to detected events orinterrupts. Software modules configured for execution on computingdevices can be provided on a computer readable medium, such as a compactdisc, digital video disc, flash drive, magnetic disc, or any othertangible medium, or as a digital download (and can be originally storedin a compressed or installable format that requires installation,decompression, or decryption prior to execution). Such software code canbe stored, partially or fully, on a memory device of the executingcomputing device, for execution by the computing device. Softwareinstructions can be embedded in firmware, such as an EPROM. It will befurther appreciated that hardware modules can be comprised of connectedlogic units, such as gates and flip-flops, and/or can be comprised ofprogrammable units, such as programmable gate arrays or processors. Themodules or computing device functionality described herein arepreferably implemented as software modules, but can be represented inhardware or firmware. Generally, the modules described herein refer tological modules that may be combined with other modules or divided intosub-modules despite their physical organization or storage.

Computer system 100 can implement the techniques and other featuresdescribed herein using customized hard-wired logic, one or more ASICs orFPGAs, firmware and/or program logic which in combination with theelectronic device causes or programs computer system 100 to be aspecial-purpose machine. According to some embodiments, the techniquesand other features described herein are performed by computer system 100in response to one or more processors 104 executing one or moresequences of one or more instructions contained in main memory 106. Suchinstructions can be read into main memory 106 from another storagemedium, such as storage device 110. Execution of the sequences ofinstructions contained in main memory 106 causes one or more processors104 to perform the process steps described herein. In alternativeembodiments, hard-wired circuitry can be used in place of or incombination with software instructions.

The term “non-transitory media” as used herein refers to any mediastoring data and/or instructions that cause a machine to operate in aspecific fashion. Such non-transitory media can comprise non-volatilemedia and/or volatile media. Non-volatile media includes, for example,optical or magnetic disks, such as storage device 150. Volatile mediaincludes dynamic memory, such as main memory 106. Common forms ofnon-transitory media include, for example, a floppy disk, a flexibledisk, hard disk, solid state drive, magnetic tape, or any other magneticdata storage medium, a CD-ROM, any other optical data storage medium,any physical medium with patterns of holes, a RAM, a PROM, and EPROM, aFLASH-EPROM, NVRAM, any other memory chip or cartridge, a registermemory, a processor cache, and networked versions of the same.

Non-transitory media is distinct from, but can be used in conjunctionwith, transmission media. Transmission media participates intransferring information between storage media. For example,transmission media includes coaxial cables, copper wire and fiberoptics, including the wires that comprise bus 102. Transmission mediacan also take the form of acoustic or light waves, such as thosegenerated during radio-wave and infra-red data communications.

Various forms of media can be involved in carrying one or more sequencesof one or more instructions to one or more processors 104 for execution.For example, the instructions can initially be carried on a magneticdisk or solid state drive of a remote computer. The remote computer canload the instructions into its dynamic memory and send the instructionsover a telephone line using a modem. A modem local to computer system100 can receive the data on the telephone line and use an infra-redtransmitter to convert the data to an infra-red signal. An infra-reddetector can receive the data carried in the infra-red signal andappropriate circuitry can place the data on bus 102. Bus 102 carries thedata to main memory 106, from which processor 104 retrieves and executesthe instructions. The instructions received by main memory 106 canoptionally be stored on storage device 110 either before or afterexecution by one or more processors 104.

Computer system 100 can also include a communication interface 118coupled to bus 102. Communication interface 118 can provide a two-waydata communication coupling to a network link 120 that is connected to alocal network 122. For example, communication interface 118 can be anintegrated services digital network (ISDN) card, cable modem, satellitemodem, or a modem to provide a data communication connection to acorresponding type of telephone line. As another example, communicationinterface 118 can be a local area network (LAN) card to provide a datacommunication connection to a compatible LAN. Wireless links can also beimplemented. In any such implementation, communication interface 118 cansend and receive electrical, electromagnetic, or optical signals thatcarry digital data streams representing various types of information.

Network link 120 can typically provide data communication through one ormore networks to other data devices. For example, network link 120 canprovide a connection through local network 122 to a host computer 124 orto data equipment operated by an Internet Service Provider (ISP) 126.ISP 126 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 128. Local network 122 and Internet 128 both use electrical,electromagnetic, or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link 120and through communication interface 118, which carry the digital data toand from electronic device 110, are example forms of transmission media.

Computer system 100 can send messages and receive data, includingprogram code, through the network(s), network link 120 and communicationinterface 118. In the Internet example, a server 130 might transmit arequested code for an application program through Internet 128, ISP 126,local network 122 and communication interface 118. The received code canbe executed by one or more processors 104 as it is received, and/orstored in storage device 110, or other non-volatile storage for laterexecution.

FIG. 2 is a flowchart representing an exemplary method 200 fordetermining the propensity of an entity to take a specified action.While the flowchart discloses the following steps in a particular order,it is appreciated that at least some of the steps can be moved,modified, or deleted where appropriate, consistent with embodiments ofthe present disclosure. In some embodiments, method 200 can be performedin full or in part by a computer system (e.g., computer system 100). Itis appreciated that some of these steps can be performed in full or inpart by other systems.

Referring to FIG. 2 , at step 210, the computer system can access one ormore data sources that include information associated with the entity.The one or more data sources can be stored locally at the computersystem and/or at one or more remote servers (e.g., such as a remotedatabase), or at one or more other remote devices. In some embodiments,the information in the data sources can be stored in one or moremultidimensional tables. By way of example, information of a first type(e.g., bill payment amount) associated with the entity, (e.g., ahousehold), can be stored in a first multidimensional table andinformation of a second type (e.g., automobile type) associated with theentity can be stored in a second multidimensional table. In someembodiments a table can contain information associated with a singleentity. In other embodiments, a table can store information associatedwith a plurality of entities. For example, each row in the table cancorrespond to a different entity (e.g., Household #1, Household #2,etc.) and each column in the table can correspond to a payment amount.In some embodiments, the information stored in the table can includeentries associated with a temporal period. For example, a table canstore a bill payment date for each bill payment amount. The informationcan be stored as a continuous value (e.g., $800 as a bill paymentamount), as a categorical value (e.g., “Sedan” or “Coupe” as anautomobile type), as textual value, or as any other type of value. Insome embodiments, a table can be stored in either a row-orienteddatabase or a column-oriented database. For example, a row in arow-oriented table can contain information associated with an entity(e.g., Household #1) and data in the row can be stored serially suchthat information associated with the entity can be accessed in oneoperation.

In some embodiments the computer system can access the one or more datasources periodically (e.g., once a week, once a month, etc.). Thecomputer system can access the one or more data sources based on the oneor more data sources being updated (e.g., a new entry, such as paymentbill amount, is added to a table). In some embodiments, the computersystem can access the one or more data sources responsive to an inputreceived from the user. The user input can identify the entity (e.g.Household #5) for which information is requested. In some embodiments,the user input can identify a category or class of entities. Forexample, the user input can identify a class of entities that are allconsumers of a specified provisioning entity (e.g., insurance company),the user input can identify entities that are located within a specifiedgeographic region (e.g., all households within the state of Illinois),or the user input can identify any other category of entities (e.g., allhouseholds with an income over $100,000). In response to the user input,the computer system can access the one or more data sources includinginformation associated with the entities. In some embodiments, method200 can be performed periodically (e.g., once a week, once a month,etc.). In some embodiments, method 200 can be performed whenever the oneor more data sources are accessed.

At step 220, the computer system can form a record including allinformation from the one or more data sources associated with theentity. In some embodiments, the record can be formed by integrating theinformation that is associated with the entity from the one or more datasources. The record can contain a multitude of information related tothe entity. For example, the record can contain all information from theone or more data sources associated with a household (e.g., number ofmembers in household, age of each member of the household, number ofautomobiles, income, monthly bill mounts for each automobile, types ofautomobiles, etc.). In some embodiments, the record can be stored as acogroup (e.g., the cogroup shown in FIG. 4 ). In some embodiments, therecord can be stored in either a row-oriented database or acolumn-oriented database. For example, a row in a row-oriented recordcan be associated with a data source (e.g., bill payment amount) anddata in the row can be stored serially such that data associated withthat data source can be accessed in one operation.

At step 230, the computer system can filter the record for informationassociated with the specified action. For example, the specified actioncan be churn (e.g., cancellation of a subscription) and the computersystem can filter the record for information related to churn. In someembodiments, the computer system can provide context for the specifiedaction. In some embodiments, the computer system can determine whetherthe specified action will likely occur within a specified temporalperiod (e.g., one month). The computer system can filter out allinformation associated with a time that is outside (e.g., before orafter) the specified temporal period. In some embodiments, the computersystem can determine the propensity for the specified action based ononly recent events. For example, the computer system can filter outinformation associated with a time before the specified time period(e.g., stale or less relevant information). In some embodiments, eachrecord can be filtered in a slightly different way. The record can befiltered according to a user input specifying an activity or temporalperiod. In some embodiments, the record can be filtered automaticallybased on a presetting (e.g., the computer can be configured to filterout all information that is more than one year old).

At step 240, the computer system can generate, based on the record, oneor more features associated with the entity. A feature can be anydiscernable way of sorting or classifying the record (e.g., averagevalue, most recent value, most common value, etc.). In some embodiments,the computer system can generate key value pairs, wherein each key valuepair contains a feature and a value. For example, the computer systemcan generate features such as “average bill payment amount”, “averageincome”, “average number of automobiles”, etc. and corresponding valuessuch as “$670”, “$73K”, “2.3 cars”, etc. In some embodiments, featurescan be associated with a time value. For example, computer system cangenerate features for a specified temporal period (e.g., features can bebased only on the most recent values). Feature values can be representedas a continuous value (e.g., $670), as a categorical value (e.g.,“Sedan” or “Coupe”), as a textual value, or as any other type of value.In some embodiments, feature values can be classified as weightedvalues. For example, a household income of $73,000 can be represented asweighted value of {0.27 0}, {0.73 100000}.

At step 250, the computer system can process the one or more features todetermine the propensity of the entity to take the specified action. Insome embodiments, the propensity can be determined by applying a trainedmodel, such as the model described in greater detail in FIG. 3 . Theinput to the model can be key value pairs of the one or more featuresassociated with the entity and the specified actions and the output ofthe model can be the propensity of the entity to take the specifiedaction. In some embodiments, processing the one or more featuresassociated with the entity can result in a multitude of useful insightsregarding the features that influence the propensity of the entity totake the specified action. Such insights, can include, for example, thefeatures that are most influential on the propensity of the entity totake the specified action (e.g., change in income, etc.).

At step 260, the computer system can output the propensity. In someembodiments the computer system can output the propensity as acontinuous value, such as a number or percentage (e.g., 80 or 80%) or asa categorical value (e.g., “low”, “medium”, or “high”). In someembodiments, the computer system can generate a user interface, such asthe user interfaces described in greater detail in FIGS. 5 and 6 fordisplaying the propensity. In some embodiments, the computer system canoutput a plurality of propensities for a plurality of entities. Thecomputer system can output the plurality of propensities as an aseparate file (e.g., a text file or an Excel file) or as a table.

FIG. 3 shows a flowchart representing an exemplary method 300 forcreating a model to determine the propensity of an entity to take aspecified action, consistent with embodiments of the present disclosure.While the flowchart discloses the following steps in a particular order,it is appreciated that at least some of the steps can be moved,modified, or deleted where appropriate, consistent with embodiments ofthe present disclosure. In some embodiments, method 300 can be performedin full or in part by a computer system (e.g., computer system 100). Itis appreciated that some of these steps can be performed in full or inpart by other systems.

Referring to FIG. 3 , at step 310, the computer system can access one ormore data sources that include information associated with the pluralityof entities. The one or more data sources can be stored locally at thecomputer system and/or at one or more remote servers (e.g., such as aremote database), or at one or more other remote devices. In someembodiments, the information in the data sources can be stored in one ormore multidimensional tables. By way of example, information of a firsttype (e.g., bill payment amount) associated with the plurality ofentities, (e.g., households), can be stored in a first multidimensionaltable and information of a second type (e.g., automobile type)associated with the entities can be stored in a second multidimensionaltable. In some embodiments a plurality of table can contain informationassociated with the plurality of entities, wherein each table containsinformation associated with each entity. In other embodiments, a tablecan store information associated with a plurality of entities. Forexample, each row in the table can correspond to a different entity(e.g., Household #1, Household #2, etc.) and each column in the tablecan correspond to a payment amount. In some embodiments, the informationstored in a table can include entries associated with a temporal period.For example, a table can store a bill payment date for each bill paymentamount. The information can be stored as a continuous value (e.g., $800as a bill payment amount), as a categorical value, (e.g., “Sedan” or“Coupe” as an automobile type), as textual value, or as any other typeof value. In some embodiments, a table can be stored in either arow-oriented database or a column-oriented database. For example, a rowin a row-oriented table can contain information associated with anentity (e.g., Household #1) and data in the row can be stored seriallysuch that information associated with the entity can be accessed in oneoperation.

In some embodiments the computer system can access the one or more datasources periodically (e.g., once a week, once a month, etc.). In otherembodiments, the computer system can access the one or more data sourcesbased on the one or more data sources being updated (e.g., a new entry,such as payment bill amount, is added to a table). In some embodiments,the computer system can access the one or more data sources responsiveto an input received from the user. In some embodiments, the user inputcan specifically identify the plurality of entities (e.g., Household#1-#10,000) for use in generating the model. In some embodiments, theuser input can identify a category or class of entities. For example,the user input can identify a class of entities that are all consumersof a specified provisioning entity (e.g., insurance company), the userinput can identify entities that are located within a specifiedgeographic region (e.g., all households within the state of Illinois),or the user input can identify any other category of entities (e.g., allhouseholds with an income over $100,000). In response to a user input,the computer system can access the one or more data sources includinginformation associated with the plurality of entities.

At step 320, the computer system can form a plurality of recordsincluding information from the one or more data sources associated withthe plurality of entities, each record being associated with an entity.In some embodiments, a record of the plurality of records can be formedby integrating information from the one or more data sources informationthat is associated with an entity of the plurality of entities. Therecord can contain a multitude of information related to the entity. Forexample, the record can contain all information from the one or moredata sources associated with a household (e.g., number of members inhousehold, number of automobiles, income, monthly bill amounts for eachautomobile, etc.). In some embodiments, the record can be stored as acogroup (e.g., the cogroup shown in FIG. 4 ). In some embodiments, therecord can be stored in either a row-oriented database or acolumn-oriented database. For example, a row in a record can beassociated with a data source (e.g., bill payment amount) and data inthe row can be stored serially such that data associated with that datasource can be accessed in one operation.

At step 330, the computer system can filter the plurality of records forinformation associated with the specified action. For example, thespecified action can be churn (e.g., cancellation or non-renewal of asubscription) and the computer system can filter the record forinformation related to churn. In some embodiments, the computer systemcan provide context for (e.g., frame) the specified action. In someembodiments, the computer system can determine whether the specifiedaction will occur within a specified temporal period (e.g., one month).The computer system can filter out all information associated with atime that is outside (e.g., before or after) the specified temporalperiod. In some embodiments, the computer system can determine thepropensity for the specified action based on only recent information.For example, the computer system can filter out information associatedwith a time before the specified temporal period (e.g., stale or lessrelevant information). In some embodiments, each record can be filteredin a slightly different way. A record can be filtered according to auser input specifying an activity or temporal period. In someembodiments, the record can be filtered automatically based on apresetting (e.g., the computer can be configured to filter out allinformation that is more than one year old).

The computer system can frame the record by associating a label with therecord. In some embodiments, the label can represent whether the entitytook the specified action within the specified temporal period. Forexample, the computer system can associate a label of “1” or “true” ifthe entity took the specified action within the specified temporalperiod. By way of example, in the context of the cancellation of asubscription, the computer system can keep data from time period A to B(e.g., the specified temporal period) and determine whether the entitycancelled the subscription within a second time period, T. In thisexample, if the entity cancelled the subscription in time period T, thecomputer system can associate a label with the record indicating thatthe entity took the specified action.

At step 340, the computer system can create, for each record, a labelledexample by generating one or more features associated with an entity ofthe plurality of entities. A feature can be any discernable way ofsorting or classifying the record (e.g., average value, most recentvalue, most common value, etc.). In some embodiments, the computersystem 340 can generate key value pairs, wherein each key value paircontains a feature and a value. For example, the computer system cangenerate features such as “average bill payment amount”, “averageincome”, “average number of automobiles”, etc. and corresponding valuessuch as “$670”, “$73K”, “2.3 cars”, etc. In some embodiments, featurescan be associated with a time value. For example, computer system cangenerate features for a specified temporal period (e.g., features can bebased only on the most recent values). Feature values can be representedas a continuous value (e.g., $670), as a categorical value (e.g.,“Sedan” or “Coupe”), as a textual value, or as any other type of value.In some embodiments, feature values can be classified as weightedvalues. For example, a household income of $73,000 can be represented asweighted value of {0.27 0}, {0.73 100000}. In some embodiments, thelabelled example can include the key value feature pairs and the recordlabel (e.g., whether the entity took the specified action).

At step 350, the computer system can select a subset of the plurality oflabelled examples to train a model. In some embodiments, the subset canbe created by randomly sampling the plurality of labelled examples. Arandom sample can allow for broader generalization of the model createdat step 360. In some embodiments, the user can select the subset oflabelled examples. For example, the user can select all entities with aparticular feature (e.g., all households with at least 2 cars). In someembodiments, the subset can be created by sampling labelled exampleswith a wide range of values for features that are known to be moreimportant (e.g., change in income).

At step 360, the computer system can train a model using the subset oflabelled examples. For example, the model can be trained by generalizinga function that maps inputs (e.g., the one or more features) to outputs(e.g., the label, such as whether the specified action occurred). Insome embodiments, the model can perform regressions for each featuresimultaneously. In some embodiments, the model can be trained by ahyperparameter optimization algorithm. In some embodiments, thehyperparameter optimization algorithm can perform a grid search througha hyperparameter space for the optimal hyperparameters. In someembodiments, the hyperparameter algorithm can perform a random searchthrough the hyperparameter space. The computer system can evaluate thehyperparameters against a holdout set of labelled examples. For example,the computer system can apply the model trained by hyperparameteroptimization to the holdout set. In some embodiments, the computersystem can retrain the model with different hyperparameters if aparticular attribute (e.g., accuracy, area under the curve,log-likelihood, F1-score, Top N, etc.) of the model does not exceed apredetermined threshold. In some embodiments, the computer system cancontinue to retrain the model until it obtains hyperparameters thatexceed the threshold value. In some embodiments, the computer system cantrain the model a predetermined number of times (e.g., 10). The computersystem can evaluate the trained models against a holdout set and selectthe model with the most favorable attributes (e.g., accuracy, area underthe curve, log-likelihood, F1-score, Top N, etc.).

At step 370, the computer system can output the model. In someembodiments, the model can be outputted to a user for future use. Forexample, a user can use the model to determine the propensity of anentity to take a specified action. In other embodiments, the computersystem can output the model to be stored locally or to be transmitted toan external database. In some embodiments, the computer system canoutput the model for use in another method, such as the method describedin FIG. 2 , to determine the propensity of an entity to take a specifiedaction. In some embodiments, the computer system can output confidencelevels for the model. For example, the computer system can output theparticular attribute (e.g., accuracy, area under the curve,log-likelihood, F1-score, Top N, etc.) of the model with respect to theexamples in the holdout set.

FIG. 4 provides an exemplary use case scenario for determining apropensity of an entity to take a specified action applied to anexemplary data structure. While the flowchart discloses the followingsteps in a particular order, it is appreciated that at least some of thesteps can be moved, modified, or deleted where appropriate, consistentwith embodiments of the present disclosure. In some embodiments, the usecase scenario shown in FIG. 4 can be performed by a computer system(e.g., computer system 100). It is appreciated that some of these stepscan be performed in full or in part by other systems.

Referring to FIG. 4 , one or more data tables 410 acquired from one ormore data sources can include information associated with the entity.The one or more data tables 410 can be stored locally at the computersystem and/or at one or more remote servers (e.g., such as a remotedatabase), or at one or more other remote devices. In some embodiments,the information in the data tables can be stored in one or moremultidimensional tables. By way of example, as shown in FIG. 4 ,information of a first type (e.g., bill payment amount) associated withthe entity, (e.g., a household), can be stored in a firstmultidimensional table 410 and information of a second type (e.g.,income or number of cars) associated with the entity can be stored in asecond multidimensional table 410. In some embodiments a table cancontain information associated with a single entity. For example, BillAmount table 410 shows the most recent bill payment amounts associatedwith the entity in this exemplary scenario. In other embodiments (notshown), a table can store information associated with a plurality ofentities. For example, each row in the table can correspond to adifferent entity (e.g., Household #1, Household #2, etc.) and eachcolumn in the table can correspond to a payment amount. In someembodiments, the information stored in the table can include entriesassociated with a temporal period. For example, a table can store a billpayment date for each bill payment amount. As shown in FIG. 4 , BillPayment Table 410 can store dates in the first column (e.g., Jan. 1,2014, Feb. 1, 2014, and Mar. 1, 2014). Each bill payment date can beassociated with the bill payment amount. For example, Bill Payment Table410 shows that an amount of $800 was billed to the household on Jan. 1,2014. The information can be stored as a continuous value (e.g., $800 asa bill payment amount), as a categorical value, (e.g., “Sedan” or“Coupe” as an automobile type), as textual value, or as any other typeof value. In some embodiments, a table can be stored in either arow-oriented database or a column-oriented database. For example, a rowin a row-oriented table can contain information associated with anentity (e.g., Household #1) and data in the row can be stored seriallysuch that information associated with the entity can be accessed in oneoperation.

The computer system can form (420) a record 430 including some or allinformation from the one or more data sources associated with theentity. In some embodiments, record 430 can be formed (420) byintegrating the information from the one or more data sources that isassociated with the entity. Record 430 can contain a multitude ofinformation related to the entity. For example, record 430 can containall information from the one or more data sources associated with ahousehold (e.g., number of members in household, number of automobiles,income, monthly bill mounts for each automobile, etc.). In someembodiments, record 430 can be stored as a cogroup with each row of thecogroup associated with a different category of information. In someembodiments, record 430 can be stored in either a row-oriented databaseor a column-oriented database. For example, a row in a row-orientedrecord can be associated with a data source (e.g., bill payment amount)and data in the row can be stored serially such that data associatedwith that data source can be accessed in one operation. As shown in FIG.4 , the “Bill Amount” is stored as row in record 430. Bill amounts $800,$600, and $600 can be stored serially such that all of the paymentamounts can be accessed in one operation. Similarly, “Income” and“Number of Cars” are stored in separate rows in record 430, andinformation from these sources (e.g. {$80K, $70K, $70K} and {3, 2, 2})can also be accessed in one operation.

In some embodiments, the computer system can filter record 430 forinformation associated with the specified action (not shown). Forexample, the specified action can be churn (e.g., cancellation of asubscription) and the computer system can filter record 430 forinformation related to churn. In some embodiments, the computer systemcan provide context for the specified action. In some embodiments, thecomputer system can determine whether the specified action will occurwithin a specified temporal period (e.g., one month). The computersystem can filter out all information associated with a time that isoutside (e.g., before or after) the specified temporal period. In someembodiments, the computer system can determine the propensity for thespecified action based on only recent events. For example, the computersystem can filter out information associated with a time before thespecified time period (e.g., stale or less relevant information). Insome embodiments, each record can be filtered in a slightly differentway. Record 430 can be filtered according to a user input specifying anactivity or temporal period. In some embodiments, record 430 can befiltered automatically based on a presetting (e.g., the computer can beconfigured to filter out all information that is more than one yearold). For example, the computer system can determine the propensity ofthe entity to take the specified action based on only data from theprevious month. In the example shown in FIG. 4 , the computer system canfilter out the older entries of Bill Amount table 410 (e.g., BillAmounts of $800 and $600 corresponding to bill dates in January andFebruary). The computer system can also filter out similar entries inIncome and Number of Cars tables 410 (e.g., incomes of $80K and $70K and3 and 2 number of cars). Thus, the computer system can use only the mostrecent entries to determine the propensity of the household to take thespecified action (e.g., $600 in Bill Amount table 410, $70K in Incometable 410, and 2 in Number of Cars table 410).

The computer system can generate (440), based on record 430, one or morefeatures 450 associated with the entity. A feature can be anydiscernable way of sorting or classifying the record (e.g., averagevalue, most recent value, most common value, etc.). In some embodiments,the computer system can generate key value pairs, wherein each key valuepair contains a feature and a value. For example, the computer systemcan generate one or more features 450 such as “average bill paymentamount”, “average income”, “average number of automobiles”, etc. andcorresponding values such as “$670”, “$73K”, “2.3 cars”, etc. In someembodiments, the one or more features 450 can be associated with a timevalue. For example, computer system can generate features for aspecified temporal period (e.g., features can be based only on the mostrecent values). Feature values can be represented as a continuous value(e.g., $670), as a categorical value (e.g., “Sedan” or “Coupe”), as atextual value, or as any other type of value. In some embodiments, theone or more feature 450 can be stored as classified as weighted values.For example, a household income of $73,000 can be represented asweighted value of {0.27 0}, {0.73 100000}.

In some embodiments, the one or more features can be extrapolated fromthe information contained in the record. For example, a feature can bethat the entity deactivated online payments (e.g. customer deactivatedETF payment on 2/20). In some embodiments, the one or more features canbe related to communications between the providing entity (e.g.,insurance provider) and consuming entity (e.g., household). For example,computer system 100 can analyze (e.g., tokenize) the transcript of acall between an agent and a household and assign a topical value to thatcall (e.g., “topic 5” corresponding to anger). Computer system 100 canstore this information as a feature pair (not shown), such as the pair{“Service Call Topic” “5”}. In some embodiments, the one or morefeatures can be related to whether the household took a specified action(e.g., filed a claim or called to change policy).

In some embodiments, the computer system can process (460) the one ormore features 450 to determine the propensity 470 of the entity to takethe specified action. In some embodiments, the propensity 470 can bedetermined by applying a trained model, such as the model described ingreater detail in FIG. 3 . The input to the model can be key value pairsof the one or more features 450 associated with the entity and thespecified actions and the output of the model can be the propensity 470of the entity to take the specified action. In some embodiments,processing the one or more features associated with the entity canresult in a multitude of useful insights regarding the features thatinfluence the propensity of the entity to take the specified action.Such insights, can include, for example, the features that are mostinfluential on the propensity of the entity to take the specified action(e.g., change in income, etc.).

In some embodiments, the computer system can output the propensity 470.In some embodiments, the computer system can output the propensity 470as a continuous value, such as a number or percentage (e.g., 80 or 80%)or as a categorical value (e.g., “low”, “medium”, or “high”). In someembodiments, the computer system can generate a user interface, such asthe user interfaces described in greater detail in FIGS. 5 and 6 fordisplaying the propensity 470.

FIG. 5 illustrates an exemplary user interface 500 provided by acomputer system (e.g., computer system 100) for display (e.g., display122), in accordance with some embodiments. User interface 500 caninclude a plurality of tiles (e.g., tile 510), each tile representing anentity (e.g., a household). In some embodiments, tiles can be arrangedaccording to the propensity of the entity to take the specified action.For example, entities that are more likely to take the specified actioncan be located near the top of the display, whereas entities that areless likely to take the specified action can be lower on the display. Asshown in FIG. 5 , in some embodiments, the tiles can be arranged by date(e.g., date 520). For example, entities with the most recent activitiescan be located near the top of the display. By way of example, tile 510with the most recent date 520 of Feb. 21, 2014 is located in the topleft corner of the display. The tile to the right of tile 510 has thenext most recent date (e.g., Feb. 20, 2014). Subsequent tiles have datesthat are less recent. In other embodiments, entities with the longestpending outstanding action can be located near the top of the screen.

In some embodiments, user interface 500 can be updated periodically(e.g., once a day, once a week, once a month, etc.). In otherembodiments, user interface 500 can be updated when informationassociated with any of the entities stored in the one or more datasources is updated (e.g., a new entry, such as payment bill amount, isadded to a table). In some embodiments, user interface 500 can update inresponse to an input received from the user.

User interface 500 can automatically determine the entities for which togenerate the display. In some embodiments, user interface 500 candisplay entities associated with a particular user (e.g., John Smith,Triage Agent) once the user accesses user interface 500. In someembodiments, the user can specifically identify the entities for whichto generate the display. In some embodiments, the user can identity acategory or class of entities for which to generate the display. Forexample, the user can identify a class of entities that are allconsumers of a specified provisioning entity (e.g., insurance company),the user input can identify entities that are located within a specifiedgeographic region (e.g., all households within the state of Illinois),or the user input can identify any other category of entities (e.g., allhouseholds with an income over $100,000).

In some embodiments, user interface 500 can portray a date 520 (e.g.,Feb. 21, 2014) associated with the entity in tile 510. Date 520 cancorrespond to the current date, the date that method 200 was lastperformed for that entity, the date that information in the one or moredata sources associated with that entity was last updated, or the datethat the user last viewed the tile associated with the entity. In someembodiments, user interface 500 can portray a propensity 540 of theentity to take the specified action (e.g., “Med”) in tile 510. Forexample, as shown in FIG. 5 , user interface 500 can portray thepropensity as a categorical value, such as “Med” in tile 510. In someembodiments, user interface 500 can portray tile 510 in a color (e.g.,green for “low”, red for “high”, etc.) representing the propensity. Insome embodiments, user interface 500 can portray the propensity in tile510 as numerical value or as a percentage.

User interface 500 can portray recent activity 530 in tile 510. In someembodiments, the recent activity 530 can be entered by a user. By way ofexample, a recent activity could be that an “Agent called customer on2/21 regarding discounts” as shown in tile 510. In some embodiments,user interface 500 can generate the recent activity based on the one ormore features associated with the entity. For example, user interface500 can display, “Customer registered an additional luxury vehicle on2/18” in tile 510 responsive to this information being updated in therecord associated with the entity. In some embodiments, tile 510 canportray important features 540 associated with the entity. For example,as shown in tile 510 of FIG. 5 , these features can be “vehicle”,“discounts”, etc. In some embodiments, user interface 500 can recommendan action for the user to take (e.g., service call). In someembodiments, this recommendation can relate to the recent activity 530.A user can use this information to take preemptive action to prevent theentity from taking the specified action. By way of example, if thepropensity of a household subscribing to an automobile insurance policywas high, the user could take remedial action (e.g., lower rate, contactcustomer to address customer concerns, etc.). In some embodiments userinterface 500 can display a number uniquely identifying the entity(e.g., a policy number).

In some embodiments, user interface 500 can allow a user to click ontile 510 to access additional information associated with the entity.For example, a user can access user interface 600 shown in FIG. 6 belowby clicking on one of the tiles shown in user interface 500 of FIG. 5 .In some embodiments, user interface 600 can be inlaid over userinterface 500. In some embodiments, user interface 600 can be a distinctuser interface.

User interface 500 can also allow access to additional user interfaces(not shown) through the “INBOX,” “FLAGGED,” and “STATS” links shown atthe top of user interface 500. The “INBOX” user interface can displaymessages between the user and other agents to track the remedial actionsthat were taken. The INBOX user interface can also be used to notifyusers of households with a higher likelihood of cancelling thesubscription. The “FLAGGED” user interface can show customers (e.g.,households) that the user believed were at risk for taking the specifiedaction. For example, the FLAGGED user interface can contain a list ofthe households most likely to cancel their insurance policy. In someembodiments, these households can be selected manually by the user. Insome embodiments, these households can be automatically populated if thepropensity exceeds a predetermined threshold (e.g., the FLAGGEDinterface can be populated with all households with a “High”propensity). The FLAGGED user interface can allow the user to trackremediation steps (e.g., contacting the household, changing policy,etc.). Households can remain in the FLAGGED user interface until theirrisk of taking the specified action has declined, the user has decidedthat the household is no longer at risk, or the specification actionoccurred (e.g., the household cancelled its subscription). The “STATS”interface can display metrics such as, for example, the rate at whichthe user was able to prevent the specified action from occurringcategorized by action taken and the most common and/or trending issues.

FIG. 6 illustrates another exemplary user interface 600 provided by thecomputer system (e.g., computer system 100) for display (e.g., display112) in accordance with some embodiments. In some embodiments, userinterface 600 can be accessed by clicking on a tile (e.g., entity) inuser interface 500. User interface 600 can portray a date 610 (e.g.,Feb. 18, 2014) associated with the entity. Date 610 can correspond tothe current date, the date that method 200 was last performed for thatentity, the date that information in the one or more data sourcesassociated with that entity was last updated, or the date that the userlast viewed the tile associated with the entity. In some embodiments,user interface 600 can portray a propensity 620 of the entity to takethe specified action. For example, as shown in FIG. 6 , user interface600 can portray propensity 620 as a categorical value, such as “Med.”.In some embodiments, user interface 600 can convey propensity 620 byshading the top bar in a different color (e.g., green for “low”, red for“high”, etc.) representing propensity 620. In some embodiments, userinterface 600 can portray propensity 620 as numerical value or as apercentage. In some embodiments user interface 600 can display theentity status 630 (e.g., “Active” if the household is currentlysubscribing to a policy).

In some embodiments, user interface 600 can display recent activities640 associated with the entity. For example, as shown in FIG. 6 , userinterface 600 can display that the “customer registered an additionalluxury vehicle on 2/18”. User interface 600 can recommend an action 650for the user to take (e.g., service call). In some embodiments, thisrecommendation 650 can relate to the recent activity.

User interface 600 can provide the user with additional informationassociated with the entity. As shown in the bottom left panel of FIG. 6, user interface 600 can display basic biographic information 660 forthe entity. In the automobile insurance context, for example, userinterface 600 can display the policy number, (e.g., 34726182), theentity name (e.g., household/owner of the policy, David Stark), thepolicy coverage start date (e.g., Dec. 12, 2004), any secondary ownersassociated with the policy (e.g., James Watson), information associatedwith the insured automobile (e.g., 2013 Cadillac Escalade), and the typeof insurance policy (e.g., Standard).

In some embodiments, user interface 600 can also display information foran agent 670 associated with the entity. For example, the user interface600 can display the name (e.g., Bruce Atherton) and contact information(e.g., 583 234-9172) of the agent. A user can use this information totake preemptive action to prevent the entity from taking the specifiedaction. By way of example, if the propensity of churning for a householdsubscribing to an automobile insurance policy was high, the user couldcontact the agent to take remedial action (e.g., lower rate, addresscustomer concerns, etc.).

In some embodiments, the right panel of FIG. 6 , can display recentevents 680 associated with the entity. For example, user interface 600can display whether the entity status is active (e.g., whether theentity is currently subscribing to a policy) or whether the agent hastaken any actions (e.g., called the household or subscriber). In someembodiments, user interface 600 can also allow the user and agent toconverse in the right panel. For example, the user can click on the “ADDAN UPDATE” button 690 to remind the agent to contact the entity. Theuser interface can display responsive comments 680 from the agent andthe agent can add any actions taken 680 (e.g., calling the household).

Embodiments of the present disclosure have been described herein withreference to numerous specific details that can vary from implementationto implementation. Certain adaptations and modifications of thedescribed embodiments can be made. Other embodiments can be apparent tothose skilled in the art from consideration of the specification andpractice of the embodiments disclosed herein. It is intended that thespecification and examples be considered as exemplary only, with a truescope and spirit of the present disclosure being indicated by thefollowing claims. It is also intended that the sequence of steps shownin figures are only for illustrative purposes and are not intended to belimited to any particular sequence of steps. As such, it is appreciatedthat these steps can be performed in a different order whileimplementing the exemplary methods or processes disclosed herein.

What is claimed is:
 1. A system comprising: one or more processors; andmemory storing instructions that, when executed by the one or moreprocessors, cause the system to: obtain information associated with aplurality of entities from one or more data sources; form a plurality ofrecords associated with the plurality of entities by integrating theinformation from the one or more data sources, each of the plurality ofrecords associated with a corresponding entity of the plurality ofentities and comprising a plurality of data entries from a specific datasource of the one or more data sources, wherein each of the plurality ofrecords stores the plurality of data entries serially; filter theplurality of records for a subset of the information associated with aspecified action and a specified temporal period; generate, based on thefiltering, a record label for each of the plurality of records; generatea key value pair for each of the plurality of records, wherein the keyvalue pair comprises a feature and a corresponding value, the featureindicating the corresponding value is an average value, and thecorresponding value comprising an average value of the plurality ofserially stored data entries from the specific data source; create a setof training data items, each training data item of the set of trainingdata items comprising a corresponding key value pair of the generatedkey value pairs and a corresponding record label of the generated recordlabels; select a subset of the training data items; obtain a model usingthe subset of training data items, wherein the obtaining comprisesconstructing multiple models using the subset of training data items,each of the multiple models having a plurality of performance metrics,and selecting one of the multiple models based on one or more of theplurality of performance metrics; determine, using the model, apropensity of a particular entity of the plurality of entities toperform a specified action; and generate a graphical user interfaceindicating the propensity of the particular entity of the plurality ofentities to perform a specified action.
 2. The system of claim 1,wherein each of the record labels indicate whether the correspondingentity performed the specified action within the specified temporalperiod.
 3. The system of claim 1, wherein the instructions further causethe system to determine, based on the trained model and a correspondingrecord of the plurality of records, a relative importance of thefeatures.
 4. The system of claim 1, wherein the graphical user interfacecomprises a plurality of tiles, each of the plurality of tiles beingassociated with a corresponding entity of a subset of the plurality ofentities.
 5. The system of claim 4, wherein a particular tile of theplurality of tiles is associated with the particular entity, and aplacement of the particular tile of the plurality of tiles within thegraphical user interface is based on the determined propensity of theparticular entity to perform the specified action.
 6. The system ofclaim 5, wherein the instructions further cause the system to update theplacement of the particular tile of the plurality of tiles within thegraphical user interfaces in response to an update of the information.7. A method for determining a propensity of an entity to take aspecified action, the method being performed by one or more processorsand comprising: obtaining information associated with a plurality ofentities from one or more data sources; forming a plurality of recordsassociated with the plurality of entities by integrating the informationfrom the one or more data sources, each of the plurality of recordsassociated with a corresponding entity of the plurality of entities andcomprising a plurality of data entries from a specific data source ofthe one or more data sources, wherein each of the plurality of recordsstores the plurality of data entries serially; filtering the pluralityof records for a subset of the information associated with a specifiedaction and a specified temporal period; generating, based on thefiltering, a record label for each of the plurality of records;generating a key value pair for each of the plurality of records,wherein the key value pair comprises a feature and a correspondingvalue, the feature indicating the corresponding value is an averagevalue, and the corresponding value comprising an average value of theplurality of serially stored data entries from the specific data source;creating a set of training data items, each training data item of theset of training data items comprising a corresponding key value pair ofthe generated key value pairs and a corresponding record label of thegenerated record labels; selecting a subset of the training data items;obtaining a model using the subset of training data items, wherein theobtaining comprises constructing multiple models using the subset oftraining data items, each of the multiple models having a plurality ofperformance metrics, and selecting one of the multiple models based onone or more of the plurality of performance metrics; determining, usingthe model, a propensity of a particular entity of the plurality ofentities to perform a specified action; and generating a graphical userinterface indicating the propensity of the particular entity of theplurality of entities to perform a specified action.
 8. The method ofclaim 7, wherein each of the record labels indicate whether thecorresponding entity performed the specified action within the specifiedtemporal period.
 9. The method of claim 7, further comprisingdetermining, based on the trained model and a corresponding record ofthe plurality of records, a relative importance of the features.
 10. Themethod of claim 7, wherein the graphical user interface comprises aplurality of tiles, each of the plurality of tiles being associated witha corresponding entity of a subset of the plurality of entities.
 11. Themethod of claim 10, wherein a particular tile of the plurality of tilesis associated with the particular entity, and a placement of theparticular tile of the plurality of tiles within the graphical userinterface is based on the determined propensity of the particular entityto perform the specified action.
 12. The method of claim 11, furthercomprising updating the placement of the particular tile of theplurality of tiles within the graphical user interfaces in response toan update of the information.
 13. A non-transitory computer-readablemedium storing a set of instructions that are executable by one or moreprocessors to cause the one or more processors to perform a method, themethod comprising: obtaining information associated with a plurality ofentities from one or more data sources; forming a plurality of recordsassociated with the plurality of entities by integrating the informationfrom the one or more data sources, each of the plurality of recordsassociated with a corresponding entity of the plurality of entities andcomprising a plurality of data entries from a specific data source ofthe one or more data sources, wherein each of the plurality of recordsstores the plurality of data entries serially; filtering the pluralityof records for a subset of the information associated with a specifiedaction and a specified temporal period; generating, based on thefiltering, a record label for each of the plurality of records;generating a key value pair for each of the plurality of records,wherein the key value pair comprises a feature and a correspondingvalue, the feature indicating the corresponding value is an averagevalue, and the corresponding value comprising an average value of theplurality of serially stored data entries from the specific data source;creating a set of training data items, each training data item of theset of training data items comprising a corresponding key value pair ofthe generated key value pairs and a corresponding record label of thegenerated record labels; selecting a subset of the training data items;obtaining a model using the subset of training data items, wherein theobtaining comprises constructing multiple models using the subset oftraining data items, each of the multiple models having a plurality ofperformance metrics, and selecting one of the multiple models based onone or more of the plurality of performance metrics; determining, usingthe model, a propensity of a particular entity of the plurality ofentities to perform a specified action; and generating a graphical userinterface indicating the propensity of the particular entity of theplurality of entities to perform a specified action.
 14. Thenon-transitory computer-readable medium of claim 13, wherein each of therecord labels indicate whether the corresponding entity performed thespecified action within the specified temporal period.
 15. Thenon-transitory computer-readable medium of claim 13, wherein thegraphical user interface comprises a plurality of tiles, each of theplurality of tiles being associated with a corresponding entity of asubset of the plurality of entities.
 16. The non-transitorycomputer-readable medium of claim 15, wherein a particular tile of theplurality of tiles is associated with the particular entity, and aplacement of the particular tile of the plurality of tiles within thegraphical user interface is based on the determined propensity of theparticular entity to perform the specified action.
 17. Thenon-transitory computer-readable medium of claim 16, further comprisinginstructions executable by the one or more processors to cause the oneor more processors to perform: updating the placement of the particulartile of the plurality of tiles within the graphical user interfaces inresponse to an update of the information.